Since the divestiture of North America's telecommunication market, there has been an increase in the amount of participants throughout the various fields of the industry: both facilities and non-facilities based. Additional competitors, e.g., competitive local exchange carriers (CLECs) have joined incumbent local exchange carriers (ILECs), local service providers (LSPs), line resellers, service providers, etc., in the telephony market.
While expanded competition has arguably benefited the public, an undesired result has included many, often confusing, choices of service providers. The increase in competition has also disrupted the fluidity of the telecommunications market that existed before divestiture for both the consumer and the market participant. One area affected by the increased amount of competitors in the telephone market is billing. A customer could potentially receive a separate billing statement for services received from each subscribed telephone service provider. Additionally, some market participants do not have the ability to sufficiently identify the end customer receiving its service.
Convergence or composite billing is an attempt to address and resolve some of the issues by providing one consolidated communications bill to the customer. The composite bill comprises charges incurred by the customer having a variety of telephone service providers, e.g., local, long distance, Internet, cell phone, paging, alternative billing, etc. This single communication bill is compiled and sent to the customer by a billing entity ultimately responsible for billing the customer. For example, a customer may contract with two different service providers for local and long distance service even though these service providers may be competitors in both local and long distance markets. One of these service providers, or perhaps some other company, may ultimately be responsible as the billing entity for providing one complete telephone communications bill to the customer. The other service providers will receive compensation dependent upon their respective business relationship with the billing entity.
Due to complexities involved with convergence billing, many industry participants may be susceptible to revenue losses because of the inability to identify the ultimate billing entity responsible for billing the party receiving its services. It is important for service providers seeking compensation to adequately identify the billing entity associated with the customer receiving such services to avoid monetary loss resulting from an unpaid service.
Presently, many phone companies utilize a line information database (LIDB) for acquiring information associated with a telephone number. LIDBs provide a variety of information. Some of the information stored in the LIDB relates to billing entities associated with telephone numbers. This information can be obtained directly, or indirectly, from fields such as operating company numbers (OCNs), account owner (AO), originating line number screening (OLNS), line providers, alternative billing services, number portability, calling features, etcetera. Typically, LIDB owners charge a fee to subscribers for accessing the information compiled within the LIDB.
An alternatively billed call, e.g., collect call, is a service provided to telephone customers wherein another party, e.g., called party, is billed for the call as opposed to the calling party or originating line number as are routinely billed. Upon receiving a request for a collect call, the telephone company ultimately responsible for billing the calling party (calling party billing entity), will attempt to identify the billing entity ultimately responsible for billing the called party (called party billing entity). This information is often obtainable through the LIDB. If the identity of the called party billing entity is not obtainable, the caller's telephone company may be reluctant to connect the call between the parties. Because of the risk involved with connecting a collect call to a called party having an unidentified billing entity, many callers' billing entities may choose not to complete the connection for the call and thus, forgo potential revenues. This loss of revenue may be due to the inability to accurately bill for services provided or the perception that the called party to be billed is not a credit worthy consumer. Regardless, potential revenues associated with unbillable and uncollected collect calls are deferred, perhaps never to be realized.
Hence there is a need for a more reliable method of managing the risks of charge backs and unbillable calls where the charges are not billed to the account associated with the line or service of the call originator.
Among the basic building blocks of the PSTN are the switching, signaling, and intelligent network service systems. The switching systems are spread throughout the world primarily as central (local) office switches or service switching points (SSP). These switches connect the line of one party to another party's line or to an outgoing interoffice transmission facility. In addition to switching calls, SSPs also provide usage measurements of calls for billing purposes. Interoffice transmission facilities consist of the physical medium—typically fiber optics or wireless—to connect switching systems.
The signaling system provides the signaling capabilities to establish a call between switching systems. The most common type of signaling used in the PSTN in the United States is referred to as Common Channel Signaling System Number 7 (CCS/SS7 or simply SS7). A telecommunications network that uses SS7 signaling sends signaling messages or packets over a packet network to exchange call control and service information among network elements. SS7 is a key element in supporting a large number of applications in telecommunications networks ranging from call control or basic call setup, to intelligent network services and efficient interconnection of networks.
Intelligent network elements include a variety of adjuncts, intelligent peripherals and databases that enable sophisticated services, such as toll free service, calling card services and other intelligent network-based services. Not all networks contain intelligent network capabilities, thus severely limiting the ability of the network operator to provide sophisticated services and maximize their basic network infrastructure.
A particular type of network architecture that most ILECs employ is referred to as an advanced intelligent network (AIN or IN) architecture. Within a basic AIN architecture, the switching, signaling and service network elements may include SSPs, signal transfer points (STP), signaling points (SP), and signaling control points (SCP). In a basic AIN architecture terminals (such as telephones, computers, cell phones, etcetera) are coupled through local loops to SSPs in the central offices. These terminals are then coupled through links to an STP and from there to an SCP.
In practice many other AIN architectures exists having one or more SSPs coupled to one or more STPs. These STPs may in turn be coupled to one or more SCPs which in turn may be coupled to one or more STPs. Any number and type of terminals can be coupled to one or more SSPs.
In these architectures, SSPs are used for switching calls and establishing transmission paths to connect the calling party to a called party. The SSPs formulate and process SS7 messages for call setup and intelligent network services. A conventional SSP formulates two basic types of messages: ISDN user part (ISUP) messages that are used to support basic call set up and transaction capabilities application part (TCAP) messages that are used to support intelligent network services, such as toll free service. These messages typically carry a request or query for information or they carry information responding to a service request.
Generally STPs are packet switches with limited intelligence used to route the signaling messages between network elements. SCPs maintain service logic and database information in support of AIN services.
A Basic Call Model has been developed for describing the processing done by an SSP in connection with the AIN to establish a two-party call. The Call Model identifies various points in call (PICs). PICs are stages of processing a call, beginning with off-hook by the calling party through on-hook by either party. The Call Model consists of half-call models: the originating basic call model (OBCM) and the terminating basic call model (TBCM). Under the AIN Call Model, there are two types of events that cause SSPs to communicate with an SCP during a call, namely triggers and requested events.
Events may occur at certain PICs called detection points (DPs). Triggers specify a condition under which an AIN SSP should suspend call processing and invoke AIN service logic. In response to a trigger the relevant SSP involved with an attempted call queries service logic residing in the relevant SCP to produce instructions for influencing subsequent call processing. For example, an origination attempt trigger detection point (TDP) is encountered after an SSP has received a call setup request. The “off-hook immediate” trigger can be placed at this TDP to initiate a TCAP query to the SCP. The SCP will then contain service logic that instructs the SSP how to process the call. Industry standards have established a basic set of TDPs and triggers.
Events are detected as a result of processing a call. AIN enables an SCP to send a next event list (NEL) of subsequent events that may occur during a call handled by an AIN SSP. Accordingly, when any of the events on the list occurs, the SSP may be required to suspend call processing and launch a query to the relevant SCP.
There are two general types of requested events. A first type of requested event are the event detection point (EDP) requests (EDP-Requests). A second type of requested event are the EDP notifications (EDP-Notifications).
In response to an EDP-Request, an SSP stops call processing, sends an EDP-Request message in a TCAP query to the SCP. The SCP waits for instructions from the SCP for further call handling.
In response to an EDP-Notification the SSP sends an EDP-Notification message to the SCP but the SCP does not await a response from the SCP, which does not respond to the SSP. However, the SSP may record the occurrence of the event. These event and trigger capabilities establish the service and control logic of the SCP.
Simple services that utilize the AIN architecture first invoke a TCAP query to an SCP. The TCAP query is routed through one or more STPs to the appropriate SCP. The SCPs recognize the type of query and acquires the appropriate information to generate a return TCAP response message that is sent back to the originating SSP. The SSP then handles the call accordingly. The action taken in response to a TCAP may be a simple look-up, or more complex service logic that will route the call to different resources (e.g., a different directory number based on a parameter such as time of day or geographic location of the originating call). If the proper information to respond to the TCAP query is not contained in the originating SSP, the originating SSP will launch an ISUP message to setup the call with the interconnecting switches.
The SS7 switching network can thus provide real time call handling with intelligence provided. However, the intelligence provided is (a) not very sophisticated in relation to reducing risks for uncollectable or unbillable calls; and (b) is not readily accessible in a real-time sense from non-ILEC entities without relatively large fees.